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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 
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(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

2003/0004874 Ludwig 1-2003 

2002/0032692 Suzuki 3-2002 



(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1, 6, 8, 10, 12-14, 16, 18-20, 22, 24-25 and 28-29 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ludwig et al. (Ludwig hereinafter) (U.S. PG 
Pub No. 2003/0004874) in view of Suzuki et al. (Suzuki hereinafter) (U. S. PG Pub No. 
2002/0032692). 
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With respect to claim 1 , Ludwig teaches "a computer readable storage 
medium for storing an electronic data record, of an invoice, the electronic data 
record comprising" as the system may allow data to be entered for the following 
exemplary fields, which the system may be adapted to store as global information on 
the database: name, address, city, state, zip, country, phone, number, fax number, and 
maximum invoice amount allowed. The system may use the maximum invoice amount 
allowed field to establish a threshold for a maximum payment for a single invoice 
(Ludwig Paragraph 0075). 

"a state data field corresponding to the invoice, the state field including an 
identification of a current state of a processing of the invoice, the current state 
being assigned by a user through a dialogue displayed on a display device" as 
"Paid Through Another Source" may be provided by the system as an option for the 
biller system user to mark an invoice as closed by selecting desired invoices and 
clicking on the "Paid through another source" button. Once this occurs, the system 
may, for the invoices in question, update their audit trail to reflect that they were paid 
outside the system, and then change their status to closed (Ludwig Paragraph 0091 & 
0130). Therefore the user is entering the current state "closed" by clicking on the 
button. Therefore the identification of the current invoice is that it is paid and closed. 

Further Ludwig teaches the filter area, the system may provide the following 
exemplary choices: by date (past due, eligible for discount, due within xxx days); and by 
status (paid invoices, adjusted invoices, unpaid invoices, paid through another source); 
and by payer (all payer, specific payer); and by attribute range between xxx and yyy 
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(none, invoice numbers, store/location, purchase orders, purchase request number, 
invoice issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, 
invoice aging) (Ludwig Paragraph 0080). These lines also teach the identification of 
the current state of the processing of the invoice. 

"a link to an event table comprising corresponding events which can occur 
during the processing of the invoice" as the system may link the status field to the 
invoice history page, at which the system may display a full status history for the 
selected invoice. By default, the system may display the following exemplary columns: 
payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 
number, P.O. requisition number, store number, and select (Ludwig Paragraph 0092). 
Therefore, these lines teach that the status field is being linked to the history page 
which contains the current status of an invoice. 

Further Ludwig teaches the system may permit biller system users to be 
associated with specific system events, which associations the system may be adapted 
to store as global information on the database. Any time one of these specific events 
occurs, the system may generate an automatic e-mail and send it to the selected list of 
biller system users. For example, exemplary distribution list choices may include: 
invoices loaded successfully, invoices loaded unsuccessfully, invoice adjusted, payment 
authorized, payment canceled, payment completed, and payment notification (Ludwig 
Paragraph 0104). These lines teaches associations between biller system containing 
invoices with specific events such as invoice adjusted, payment authorized, payment 
canceled, payment completed, and payment notification. 
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"a link to a proposal table comprising corresponding proposed action for 
changing the corresponding states" as the system may identify an invoice as having 
one of the following exemplary states: presented, viewed (an invoice may be considered 
"viewed" when a invoice display query is built with the invoice included; the user does 
not necessarily need to actually see the invoice to have it considered viewed), verified 
(an invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127 and 0130-0133 and 
0065, 0152). 

In the above paragraphs Ludwig teaches an invoice being rolled from one state 
to another such as verified to viewed or viewed to verified. 

"a plurality of states of the processing of the invoice" as the perspective of 
the payer system user, the system may identify an invoice as having one of the 
following exemplary states: presented, viewed (an invoice may be considered "viewed" 
when a invoice display query is built with the invoice included; the user does not 
necessarily need to actually see the invoice to have it considered viewed), verified (an 
invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127). 
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"a comment data field corresponding to the invoice, the comment data field 
comprising comments entered by the user through the dialogue" as the system 
may provide a notes button 617 for opening a separate browser window 627 containing 
a list of entered notes for this invoice. In the separate browser window, the system may 
permit the user to enter new notes into a new note textbox and save them by clicking an 
"add note" button (Ludwig Paragraph 0094). 

Ludwig teaches the elements of claim 1 as noted above but does not explicitly 
discloses, "links to tables with plurality of possible states" "a first link to a 
description table comprising identifications of a plurality of possible states of the 
invoice during the processing of the invoice and corresponding descriptions of 
the plurality of possible states, and a second link to an instruction table 
comprising the identifications of the plurality of possible states and 
corresponding instructions automatically executed by a computer the instruction 
comprising workflow automatically initiated by the computer." 

However, Suzuki discloses, "links to tables with plurality of possible states" 
as (Suzuki Figures 4-5). 

"a first link to a description table comprising identifications of a plurality of 
possible states of the invoice during the processing of the invoice and 
corresponding descriptions of the plurality of possible states" as (Suzuki 
Paragraphs 0065, 0071, 0147, and 0183). 

"a second link to an instruction table comprising the identifications of the 
plurality of possible states and corresponding instructions automatically 
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executed by a computer the instruction comprising workflow automatically 
initiated by the computer" as (Suzuki Paragraphs 0019-0020, 0064, 0073, 0145 and 
0150). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Suzuki's 
teaching would have allowed Ludwig to provide a more flexible workflow management 
system by storing process definitions such as possible states and transitions and by 
calling and executing API's provided by the workflow management program. 

With respect to claim 6, Ludwig teaches "wherein the electronic data record 
is at least partially accessible via the Internet and wherein the content of the data 
field for the current state or a data field for comments is editable via the Internet" 

as the system may permit information to be maintained and edited at this page, which 
the system may store as global information on the database (Ludwig Paragraph 0064). 
The present invention may be appropriately adapted to include such communication 
functionality and Internet browsing ability (Ludwig Paragraph 0157). 

With respect to claim 8, Ludwig teaches "a computer implemented method 
for processing an electronic data record of an invoice, the method comprising" as 

the system may allow data to be entered for the following exemplary fields, which the 
system may be adapted to store as global information on the database: name, address, 
city, state, zip, country, phone, number, fax number, and maximum invoice amount 
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allowed. The system may use the maximum invoice amount allowed field to establish a 
threshold for a maximum payment for a single invoice (Ludwig Paragraph 0075) 

"displaying a dialogue on a display device for enabling a user to assign a 
current state of a processing of the invoice and storing using a processor, an 
identification of the current sate of the invoice in a state data field corresponding 
to the invoice in the electronic data record" as "Paid Through Another Source" may 
be provided by the system as an option for the biller system user to mark an invoice as 
closed by selecting desired invoices and clicking on the "Paid through another source" 
button. Once this occurs, the system may, for the invoices in question, update their 
audit trail to reflect that they were paid outside the system, and then change their status 
to closed (Ludwig Paragraph 0091 & 0130). Therefore the user is entering the state 
"closed" by clicking on the button. Therefore the identification of state of the current 
invoice is being stored/updated such as paid and closed. 

"a link to an event table comprising corresponding events which can occur 
during the processing of the invoice" as the system may link the status field to the 
invoice history page, at which the system may display a full status history for the 
selected invoice. By default, the system may display the following exemplary columns: 
payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 
number, P.O. requisition number, store number, and select (Ludwig Paragraph 0092). 
Therefore, these lines teach that the status field is being linked to the history page 
which contains the current status of an invoice. 
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Further Ludwig teaches the system may permit biller system users to be 
associated with specific system events, which associations the system may be adapted 
to store as global information on the database. Any time one of these specific events 
occurs, the system may generate an automatic e-mail and send it to the selected list of 
biller system users. For example, exemplary distribution list choices may include: 
invoices loaded successfully, invoices loaded unsuccessfully, invoice adjusted, payment 
authorized, payment canceled, payment completed, and payment notification (Ludwig 
Paragraph 0104). 

These lines teaches associations between biller system containing invoices with 
specific events such as invoice adjusted, payment authorized, payment canceled, 
payment completed, and payment notification. 

"a link to a proposal table comprising corresponding proposed action for 
changing the corresponding states" as the system may identify an invoice as having 
one of the following exemplary states: presented, viewed (an invoice may be considered 
"viewed" when a invoice display query is built with the invoice included; the user does 
not necessarily need to actually see the invoice to have it considered viewed), verified 
(an invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127 and 0130-0133 and 
0065, 0152). 
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In the above paragraphs Ludwig teaches an invoice being rolled from one state 
to another such as verified to viewed or viewed to verified. 

"a plurality of states of the processing of the invoice" as the perspective of 
the payer system user, the system may identify an invoice as having one of the 
following exemplary states: presented, viewed (an invoice may be considered "viewed" 
when a invoice display query is built with the invoice included; the user does not 
necessarily need to actually see the invoice to have it considered viewed), verified (an 
invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127). 

"a comment data field corresponding to the invoice, the comment data field 
comprising comments entered by the user through the dialogue" as the system 
may provide a notes button 617 for opening a separate browser window 627 containing 
a list of entered notes for this invoice. In the separate browser window, the system may 
permit the user to enter new notes into a new note textbox and save them by clicking an 
"add note" button (Ludwig Paragraph 0094). 

Ludwig teaches the elements of claim 8 as noted above but does not explicitly 
discloses, "a first link to a description table comprising identifications of a 
plurality of possible states of the invoice during the processing of the invoice and 
corresponding descriptions of the plurality of possible states, and a second link 
to an instruction table comprising the identifications of the plurality of possible 
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states and corresponding instructions automatically executed by a computer the 
instructions comprising a workflow automatically initiated by the computer." 

However, Suzuki discloses, "links to tables with plurality of possible states" 
as (Suzuki Figures 4-5). 

"a first link to a description table comprising identifications of a plurality of 
possible states of the invoice during the processing of the invoice and 
corresponding descriptions of the plurality of possible states" as (Suzuki 
Paragraphs 0065, 0071, 0147, and 0183). 

"a second link to an instruction table comprising the identifications of the 
plurality of possible states and corresponding instructions automatically 
executed by a computer the instructions comprising a workflow automatically 
initiated by the computer" as (Suzuki Paragraphs 0019-0020, 0064, 0073 and 0145). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Suzuki's 
teaching would have allowed Ludwig to provide a more flexible workflow management 
system by storing process definitions such as possible states and transitions and by 
calling and executing API's provided by the workflow management program. 

With respect to claim 10, Ludwig teaches "the method of claim 8, further 
comprising: performing at least one of selecting, sorting, evaluating, and 
analyzing the electronic invoice according to the current state" as the system may 
provide a sort area to allow returned results to be sorted in ascending or descending 
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order according to the following exemplary criteria: due date, invoice number, invoice 
date, purchase order number, net amount due, store or location number, and invoice 
aging (Ludwig Paragraph 0080). 

With respect to claim 12, Ludwig teaches "wherein the current state is 
selectable by the user according to predefinable events" as in this section, the 
system may permit biller system users to be associated with specific system events, 
which associations the system may be adapted to store as global information on the 
database. Any time one of these specific events occurs, the system may generate an 
automatic e-mail and send it to the selected list of biller system users. For example, 
exemplary distribution list choices may include: invoices loaded successfully, invoices 
loaded unsuccessfully, invoice adjusted, payment authorized, payment canceled, 
payment completed, and payment notification (Ludwig Paragraph 0104). The system 
may only permit invoices with the status of "paid", "presented", or "viewed" to be closed. 
All other invoice states may indicate payer workflow is in progress, and the system may 
not permit invoices having such states to be closed (Ludwig Paragraph 0105). 

The system may permit a biller system user to select an option 605 to display 
invoices based on selected criteria and/or specify general search criteria for listing 
invoices. Depending on the selection, the system may direct the user to a "view 
options" page 606 for filtering and sorting (Ludwig Paragraph 0080). 



Application/Control Number: 10/770,423 Page 14 

Art Unit: 2166 

With respect to claim 13, Ludwig teaches "the method of claim 8, wherein the 
method is for use in business software, or enterprise resource planning 
software" as the business service provider system 16 may be an exchange or other 
service bureau application providing a plurality of business processing services to its 
clients (which may include the biller system 12 and/or payer system 14). One such 
business processing service may be electronic bill presentment and payment, as may 
be provided using a system and/or method consistent with the invention (Ludwig 
Paragraph 0027). 

Group of claims 14,16,18-19 and 20, 22, 24-25 are essentially the same as 
group of claims 8,10, and 1 2-1 3 except they set forth the claimed invention as system 
and a computer-readable medium comprising instructions and are rejected for the same 
reasons as applied hereinabove. 

With respect to claim 28, Ludwig teaches "an electronic data structure for an 
electronic data record according to any one of claims 1 and 6" as the exemplary 
embodiments of the system of the present invention described herein may be embodied 
as one or more distributed computer program processes, data structures (Ludwig 
Paragraph 0156). 
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Claim 29 is essentially the same as claim 13 except it sets forth the claimed 
invention as an electronic data structure and is rejected for the same reason as applied 
hereinabove. 

(10) Response to Argument 
A. § 103(a) rejection of claims 1, 6, 8, 10, 12-14, 16, 18-20, 22, 24-25, and 28-29 
over Ludwig in view of Suzuki. 

Appellant argues that Ludwig and Suzuki fail to disclose or suggest "an 
instruction table comprising the identification of the plurality of possible states 
and corresponding instructions automatically executed by a computer" and "an 
event table comprising the identification of the plurality of possible states and 
corresponding events which can occur during the processing of the invoice" as 
recited in independent claim 1. 

In response to the preceding arguments examiner respectfully submits that 
Ludwig teaches "an event table comprising corresponding events which can 
occur during the processing of the invoice" as the system may link the status field to 
the invoice history page, at which the system may display a full status history for the 
selected invoice. By default, the system may display the following exemplary columns: 
payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 
number, P.O. requisition number, store number, and select (Ludwig Paragraph 0092, 
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0080). Further Ludwig teaches the system may permit biller system users to be 
associated with specific system events, which associations the system may be adapted 
to store as global information on the database. Any time one of these specific events 
occurs, the system may generate an automatic e-mail and send it to the selected list of 
biller system users. For example, exemplary distribution list choices may include: 
invoices loaded successfully, invoices loaded unsuccessfully, invoice adjusted, payment 
authorized, payment canceled, payment completed, and payment notification (Ludwig 
Paragraph 0104). 

First of all examiner would like point that the Ludwig's invention is using a 
relational database 36 and all the data is organized into tables as recited in Ludwig's 
paragraph 0048. 

Further, the above lines teach associations/links between biller system 
containing invoices with current state and specific events such as invoice adjusted, 
payment authorized, payment canceled, payment completed, and payment notification. 
Examiner interprets the invoice adjusted, payment authorized, payment canceled, 
payment completed, and payment notification as the corresponding events because 
they take place/occur based on the current state of the invoice. 

Ludwig teaches elements of the argued limitation but does not explicitly teaches 
"tables with plurality of possible states" "an instruction table comprising the 
identification of the plurality of possible states and corresponding instructions 
automatically executed by a computer." 
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However, Suzuki discloses, "tables with plurality of possible states" as 
(Suzuki Figures 2-5 and paragraphs 0064-0065). "an instruction table comprising 
the identification of the plurality of possible states and corresponding 
instructions automatically executed by a computer" as (Suzuki Paragraphs 0019- 
0020, 0064-0065, 0068, 0073, 0145, and 0150). 
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These paragraphs and the figure 2 shown above teaches that the process 
definition table 142 stores table 210 which contains plurality of possible state and stores 
definitions of these possible states and a transition definition table 211 which contains 
definition of possible transition between the states. 

The workflow data 143 and process definition data 142, determines a processing 
mode for a state transition request by a process method determination program 200 
which assigns a process to the state transition request synchronous process program 
201 or the state transition request asynchronous process program 202 in accordance 
with the contents of the transition definition table 211. Examiner interprets the process 
programs 201. 202. and 203 as being instructions automatically executed by a 
computer in accordance with the state transition request. 

Appellant further argues that Ludwig and Suzuki fail to disclose or suggest four 
tables including "a description table comprising identifications of a plurality of 
possible states of the invoice[,].., an instructions table comprising the 
identifications of the plurality of possible states of the invoice[,].., an event table 
comprising the identifications of the plurality of possible states of the invoice [,]... 
and.., a proposal table comprising the identifications of the plurality of possible 
states of the invoice," as recited in claim 1 and states that none of tables in Ludwig 
and Suzuki store possible states. 
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In response to the preceding arguments examiner would first like to point out that 
the four tables only include data which is nonfunctional descriptive material. 
"Nonfunctional descriptive material" includes but is not limited to music, literary works 
and a compilation or mere arrangement of data (MPEP section 2106.1V.B.1). In this 
case it is an arrangement of data in different table. (See In re Ngai, 367 F.3d 1336, 
1339 (Fed. Cir. 2004) and In re Gulack, 703 F.2d 1381, 1385 (Fed. Cir. 1983)). 

Further, in response to the preceding arguments examiner respectfully submits 
that examiner has rejected claims under 103 rejection and not 102. 

Ludwig's teaches "possible states of an invoice" as the system identifying an 
invoice as having one of the following exemplary states: presented, viewed (an invoice 
may be considered "viewed" when a invoice display query is built with the invoice 
included; the user does not necessarily need to actually see the invoice to have it 
considered viewed), verified (an invoice that is in this state may be rolled back to viewed 
given the user has the permission to verify), payment initiated, payment authorized, 
payment pending (an invoice in this state may be rolled back to verified given the user 
has the permission to authorize payment), paid, and closed (Ludwig Paragraph 0127). 

Therefore these lines teaches Ludwig showing possible states of an invoice as 
having payment pending, paid, closed, etc, which are being stored in the tables of 
database 36. 

Ludwig however does not explicitly disclose different tables storing possible 
states. 
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However Suzuki teaches "different tables storing possible states" as (Suzuki 

Figure 2 and paragraphs 0064-0065). 

In this figure and paragraphs Suzuki teaches different tables such as state 
definition table 210, transition definition table 211, and process instance state table 214. 
State definition table includes definition of possible states, transition definition table 211 
includes definition of possible transition between states and process instance table 214 
includes states of process instance. Therefore all these tables include plurality of 
possible states. 

Appellant further argues that Ludwig and Suzuki fail to disclose or suggest four 
links to the four tables "a state data field. ..including.., an identification of a current 
state[,].., a first link to a description table[,] .. a second link to an instructions 
table[,].., a third link to an event tablet,].., and a fourth link to a proposal table." 

In response to the preceding arguments examiner respectfully submits that 
Ludwig teaches "four links to four tables" as the system may link the invoice number 
field to the invoice detail page . The system may link the status field to the invoice 
history page , at which the system may display a full status history for the selected 
invoice. By default, the system may display the following exemplary columns: payer 
name, invoice number, due date, status, net amount due, amount to pay, P.O. number, 
P.O. requisition number, store number, and select (Ludwig Paragraph 0092 and 0130). 
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Examiner interprets the link to invoice history page as events and link to invoice 
detail page as proposal table because paragraphs 0130 explains that detail page 
includes current state of the invoices (presented, viewed or adjusted) and actions to be 
performed on the invoice such as approve invoice, verify confirm etc. 

Further Suzuki's figure 2 shows the current state being linked/referenced to the 
tables 21 0, 21 1 and 213 which are being used for the state transitioning process by use 
of a workflow management program. 

Therefore the combination of Ludwig and Suzuki teaches the claimed invention 
as a whole. 

Appellant's arguments directed towards the rejections of independent claims 8, 
14, and 20 and dependent claims 6, 10, 12-13, 16, 18-19, 22, 24-25 and 28-29 reiterate 
deficiencies Appellant made in the rejection of the independent claim 1 and do not 
address any new points. Therefore examiner submits that if the rejection of the 
independent claim 1 is deemed proper, the rejection of independent claims 8, 14 and 20 
and dependent claims 26, 10, 12-13, 16, 18-19, 22, 24-25 and 28-29 should also be 
upheld. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
Usmaan Saeed 
/Usmaan Saeed/ 
Examiner, Art Unit 2166 

Conferees: 
/Hosain T Alam/ 

Supervisory Patent Examiner, Art Unit 2166 



/Mohammad AN/ 

Supervisory Patent Examiner, Art Unit 2158 



